1. Field
The disclosed embodiments generally relate to relational database systems, and in particular to Web Feature Service (“WFS”) locking support based on a light-weight locking model in the database.
2. Brief Description of Related Developments
Web Feature Service Implementation Specification [WFS 1.0.0] proposes interfaces for describing data manipulation operations on geographic features using HTTP as the distributed computing platform. A Web Feature Service (WFS) publishes feature-level geographical data to the web and provides an interface allowing requests for geographical features across the web that are highly interoperable. It uses the XML-based Geographic Mark Up Language (GML) for data exchange. A feature is an object that is an abstraction of a real world phenomenon. An object has a set of properties, that can include for example, a name, a type and a value. On example of a feature is a Road that has a name, location, width, speed limit and jurisdiction. These features can be stored in a database, such as a spatial database, for example. Web Feature services provides for uniform access to these stored features.
A Web Feature Server (“WFS”) distributes feature information over the web using XML and provides a protocol for requesting and serving vector data over HTTP and responds to requests by returning data in GML. The Web feature server allows uniform access to features stored on a server and transactions allow a client to modify data on the server. These transactions can include, for example, querying a dataset and retrieving the features, finding a feature's property names and types, adding features to a dataset, updating or deleting features, and locking features to exclusively update a feature instance for a period of time.
The web feature service specification defines interfaces for describing data manipulation operations of geographic features, particularly in a geographic information system (“GIS”). A geographic information system is generally a system that creates and manages spatial data and attributes for geographically referenced information. In a geographic information system, real world objects are represented by digital data. Data capture in a geographic information system is a time consuming process. In many geographic information service applications, there is a need for a user to hold on to, or maintain control of a row, or feature instance, for a long period of time. Data updates or edits in these systems can take hours, days or months, and can span across multiple sessions and database shutdowns, during which time other users may need to access the same database. During the time that the user controls the row or feature instance(s), no other user should be able to implement any changes to the same feature instance(s). Also, as the user makes changes to the feature instance(s), the changes should be made available to others for viewing, but not for updating. Only when the user relinquishes the hold on the row should another user be able to access the same data.
Operations in a Web Feature Service request can include the ability to create a new feature instance, delete a feature instance, update a feature instance, get or query features based on spatial and non-spatial constraints. A web feature service describes discovery, query, or data transformation operations and a web feature service request consists of a description of query or data transformation operations (e.g. create/update/delete) that are to be applied to one or more feature instances. The request is generated on the client and is posted to a web feature server using HTTP. The web feature server then parses (reads) and executes the request.
As Web connections are inherently stateless, the semantics of serializable transactions are not preserved. For example, a client first fetches a feature instance. The feature is then modified on the client side, and submitted back to the database via a transaction request for update. Serializability is lost since there is nothing to guarantee that while the feature was being modified on the client side, another client did not come along and update that same feature in the database.
One way to ensure serializability is to require that any access or modification to data in a database be carried out in a mutually exclusive manner. It is important that while one transaction modifies a data item, no other transaction can modify the same data item. This can be accomplished by using locks that control access to the data.
One approach to long transaction management in geographic information systems and web feature services is versioning. Versioning generally involves storing changes to the database as different revision sets. Users can create new versions of data to update, while maintaining a copy of the old data. Feature instances are locked for use in a specific revision set and prevent conflicts between a parent revision set and a child revision set. The results of the long transaction can be stored persistently. Thus, users are assured that there is concurrency and consistency in the database, at the expense of the use of storage facilities by requiring the need to hold different versions of the same record in one or more revision sets so that users can change the versions independently. In the versioning approach, there is no way to lock feature instances without version-enabling it. The locks are maintained at a version-level. Also using the versioning approach, currently there is no way to obtain a long transaction lock exclusively owned by one session on a feature instance which can later be transferred to another session via a sequential hand-off. It would be advantageous to enable a locking mechanism on feature instances that is long term and transferable across web feature service requests and sessions without the need to consume valuable storage space for maintaining version data, as well as allow a WFS to derive long term and transferable locking parameters from different WFS lock feature requests.